home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
internet-drafts
/
draft-ietf-iplpdn-para-negotiation-01.txt
< prev
next >
Wrap
Text File
|
1993-07-08
|
14KB
|
437 lines
Draft Parameter Negotiation July 1993
INTERNET DRAFT
Expires: January 7, 1994
Parameter Negotiation
for the
Multiprotocol Interconnect
Keith Sklower
Computer Science Department
University of California, Berkeley
Clifford Frost
Information Systems & Technology
University of California, Berkeley
1. Status of This Memo This document is an Internet
Draft. Internet Drafts are working documents of the Inter-
net Engineering Task Force (IETF), its Areas, and its Work-
ing Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of
six months. Internet Drafts may be updated, replaced, or
obsoleted by other documents at any time. It is not appro-
priate to use Internet Drafts as reference material or to
cite them other than as a ``working draft'' or ``work in
progress.''
Please check the 1id-abstracts.txt listing contained in the
internet-drafts Shadow Directories on nic.ddn.mil,
nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or
munnari.oz.au to learn the current status of any Internet
Draft.
2. Abstract
This document describes mechanisms for negotiating opera-
tional parameters wherever SNAP encapsulation of Internet
Protocols is available. For example, it is suitable for use
in conjunction with RFC 1294 (Multiprotocol Over Frame
Relay) and RFC 1356 (Multiprotocol Interconnect on X.25 and
ISDN in the Packet Mode) [1,2], and potentially others. The
mechanisms described here are intended as optional exten-
sions, intended to facilitate interoperation in public net-
works were preconfiguration may not have been done symmetri-
cally by all parties who wish to exchange information.
Sklower & Frost [Page 1]
Draft Parameter Negotiation July 1993
3. Acknowledgements
The authors wish to thank Brian Lloyd of Lloyd & Associates
and Bill Simpson of Daydreamer, Inc. for extensive discus-
sion of the PPP protocol, Brad Steinke of Microcom, and Joel
Halpern of Network Systems for useful suggestions, and espe-
cially Chris Ranch of Novell for details about the protocol
itself.
4. Conventions
The following language conventions are used in the items of
specification in this document:
o Must, Shall or Mandatory -- the item is an absolute
requirement of the specification.
o Should or Recommended -- the item should generally be
followed for all but exceptional circumstances.
o May or Optional -- the item is truly optional and may
be followed or ignored according to the needs of the
implementor.
5. Introduction
When parties wish to exchange information over a public data
network, it may be useful to perform sanity checks, such as
verifying that buffer sizes are sufficient to receive data
being transmitted, or that there is agreement as to which
protocols will be routed or bridged. As another example,
there may be circumstance in which the identity of a calling
party may not be readily available; thus some form of
authentication may be desired.
The Point-to-Point Protocol (RFC 1331 and 1332) provides a
means of achieving these goals [3,4]. It is very general
and can be adapted to any situation where there is a virtual
point-to-point connection between parties wishing to
exchange information. Both RFC's 1294 and 1331 specify
details of framing and encapsulation in incompatible ways;
however, one can accommodate PPP's encapsulation of control
packets by prepending a SNAP header without otherwise chang-
ing the description of the packets.
Alternatively, should ISO or CCITT be persuaded to grant an
NLPID (identifier for use in ISO TR 9577[6]), the PPP pack-
ets and encapsulations could co-exist as an extension to
RFC's 1294 and 1356.
Members of the IPLPDN group expressed the desire that param-
eter negotiation as a whole be made optional, and also
wanted to be able to renegotiate parameters at any time
Sklower & Frost [Page 2]
Draft Parameter Negotiation July 1993
during the course of an association. Both of these goals
can be met without violating the current PPP spec.
6. Frame Format
6.1. Basic Format
In this document, we propose prepending a SNAP header to
otherwise unchanged PPP (data and control) packets [5]. The
SNAP header MUST specify an OUI of 0 (Xerox Ethernet Encap-
sulation). The protocol ID field MUST be 0x0B03. A system
SHOULD recognize incoming PPP data packets. We RECOMMEND
that only control or negotiation type PPP packets be trans-
mitted in this fashion, since RFCs 1294 and 1356 already
specify a means of encapsulating data packets.
Since we are proposing using this in conjunction with both
RFC1294 and RFC1356, we give an example in each packet for-
mat:
Sample Frame Relay PPP LCP packet
+-----------------------------+
| flag (7E hexadecimal) |
+-----------------------------+
| Q.922 Address |
+-- --+
| |
+-----------------------------+
| Control (UI = 0x03) |
+-----------------------------+
| Optional Pad(s) (0x00) |
+-----------------------------+
| NLPID 0x80 |
+-----------------------------+
| OUI 0x00 |
+-- . --+
| OUI 0x00 |
+-- . --+
| OUI 0x00 |
| (three octets) |
+-----------------------------+
| ETHERTYPE 0x0B |
+-- . --+
| ETHERTYPE 0x03 |
| (two octets) |
+-----------------------------+
| PPP Protocol (e.g. 0x0c) |
+-- . --+
| PPP Protocol (0x21 for LCP)|
| (two octets) |
+-----------------------------+
| Data |
Sklower & Frost [Page 3]
Draft Parameter Negotiation July 1993
| (e.g LCP Code ) |
+-----------------------------+
| (e.g LCP Identifier) |
+-----------------------------+
| (e.g. LCP Option Length)|
+-- . --+
| (two octets) |
+-----------------------------+
| (e.g. LCP Option) |
| . |
| . |
| . |
| . |
+-----------------------------+
| Frame Check Sequence |
+-- . --+
| (two octets) |
+-----------------------------+
| flag (7E hexadecimal) |
+-----------------------------+
Sample X.25 PPP LCP packet
+-----------------------------+
| flag (7E hexadecimal) |
+-----------------------------+
| Address A or B 0x1 or 0x3 |
+-- --+
| LAPB Control |
+-----------------------------+
| D,Q bits | SVC# high order |
+-----------------------------+
| SVC low order |
+-----------------------------+
| p(r) | m_bit | p(s) | 0 |
+-----------------------------+
| NLPID 0x80 |
+-----------------------------+
| OUI 0x00 |
+-- . --+
| OUI 0x00 |
+-- . --+
| OUI 0x00 |
| (three octets) |
+-----------------------------+
| ETHERTYPE 0x0B |
+-- . --+
| ETHERTYPE 0x03 |
| (two octets) |
+-----------------------------+
| PPP Protocol (e.g. 0x0c) |
+-- . --+
| PPP Protocol (0x21 for LCP)|
Sklower & Frost [Page 4]
Draft Parameter Negotiation July 1993
| (two octets) |
+-----------------------------+
| Data |
| (e.g LCP Code ) |
+-----------------------------+
| (e.g LCP Identifier) |
+-----------------------------+
| (e.g. LCP Option Length)|
+-- . --+
| (two octets) |
+-----------------------------+
| (e.g. LCP Option) |
| . |
| . |
| . |
| . |
+-----------------------------+
| Frame Check Sequence |
+-- . --+
| (two octets) |
+-----------------------------+
| flag (7E hexadecimal) |
+-----------------------------+
Since one of the packet formats specified in RFC1356 permits
logically prepending the call user data supplied when the
virtual circuit was established to each packet transmitted
over that virtual circuit, one could transmit PPP packet
unchanged if the 6 byte snap header is supplied as the call
user data. Equivalently, if a NLPID for PPP is obtained,
then the single byte NLPID is all that is required as CUD.
6.2. Supported Types
The PPP protocol is a rich language and allows many options
to be negotiated. An implementation MAY request any option
specified by PPP, but MAY decline to support any option.
Because PPP and Frame Relay encapsulations evolved indepen-
dently, there are duplicate ways to obtain configuration
information such as the IP address of the other end of the
PVC - by inverse arp, or determine the transmit and receive
buffer sizes - by XID negotiation. Where there are such
choices, it is RECOMMENDED that an implementation adhere to
practice specified in the Frame Relay and X.25 RFCs. Manual
configuration also implicitly provides information that may
otherwise have been explicitly negotiated.
7. Changes to PPP semantics
7.1. Optionality and Separability of Negotiations
As noted above, people have expressed the desire not to be
required to conduct any negotiations before transmitting
Sklower & Frost [Page 5]
Draft Parameter Negotiation July 1993
data packets in a public data network environment. Thus, an
implementation MAY silently ignore any SNAP encapsulated PPP
packet. If an implementation responds to LCP packets, it
MUST traverse the LCP state diagram according to RFC1331.
If an implementation responds to NCP packets for any partic-
ular protocol, it MUST otherwise obey the rules of the RFC
for that corresponding NCP.
One reason for making negotiations optional is cost; there
are environments which charge by the packet and there are
applications such as mail hubs which generally exchange only
a few data packets with a given remote host and then will
not exchange any other packets for relatively long periods
of time.
Another reason is simplicity of implementation. For use of
small computers at home, people may wish to be able to only
support the required packet framing. Or, for routers at
campus or business hubs, this could reduce memory require-
ments from having to maintain state information for hundreds
of virtual point-to-point connections.
Another reason is reduction of latency.
8. References
[1] Bradley, T., Brown, C., and Malis, A., "Multiprotocol
Interconnect over Frame Relay", Network Working Group,
RFC-1294, January 1992.
[2] Malis, A., Robinson, D., Ullman R., "Multiprotocol
Interconnect on X.25 and ISDN in the Packet Mode", Net-
work Working Group, RFC-1356, August 1992.
[3] Simpson, W., "The Point-to-Point Protocol (PPP) for the
Transmission of Multi-protocol Datagrams over Point-to-
Point Links", Network Working Group, RFC-1331, May
1992.
[4] McGregor, G., "The PPP Internet Protocol Control Proto-
col (IPCP)" Network Working Group, RFC-1332, May 1992.
[5] Postel, J. and Reynolds, J., "A Standard for the Trans-
mission of IP Datagrams over IEEE 802 Networks", ISI,
RFC-1042, February 1988.
[6] International Organization for Standardization, "Infor-
mation technology - Telecommunications and Informations
exchange between systems - Protocol identification in
the network layer", Technical Report 9577, October
1990.
Sklower & Frost [Page 6]
Draft Parameter Negotiation July 1993
9. Authors' Addresses
Keith Sklower
Computer Science Department
570 Evans Hall
University of California
Berkeley, CA 94720
Phone: (510) 642-9587
E-mail: sklower@cs.Berkeley.EDU
Clifford Frost
Information Systems & Technology
275 Evans Hall
University of California
Berkeley, CA 94720
Phone: (510) 642-5360
E-mail: cliff@cmsa.Berkeley.EDU
10. Expiration Date of this Draft
January 7, 1994
Sklower & Frost [Page 7]